BizTalk Server 2009 : Exposing WCF services from schemas

For this scenario, we will:

• Configure a TCP endpoint in BizTalk Server

• Generate a WCF metadata service hosted in IIS that clients use to discover the service and its true service URI

• Build the metadata endpoint using only schemas and no orchestrations

We will reuse the previously-built NewOrder_XML.xsd schema as the input message to the new service. This means that this new scenario requires no new development on our part. The scenario begins with the creation of a new receive port and location in the BizTalkSOA application found in the BizTalk Administration Console. The receive port has the following attributes:

Next, we'll take this receive port and add a new receive location to it with the following attributes:

Once the receive location is created, it should be started to ensure that it was configured correctly. An example of an incorrect configuration would be the designation of a URI port that was already in use by other processes. If this situation occurs, a message is added to the Application Event Log explaining the port collision.

Now as we talked before, BizTalk receive locations are never associated with a particular XSD schema. So, if we are assuming that our service client(s) does not have a copy of the service contract already, then we must provide a metadata endpoint that explains the type of message that our in-process receive location expects. In the previous section, we saw that the WCF endpoints generated from BizTalk orchestrations have verbose descriptions and burden you with lengthy attribute names. In many cases, you will want more fine-grained control over the service definition than what the Publish BizTalk orchestrations as WCF service selection in the BizTalk WCF Service Publishing Wizard can give you. In fact, unless you are desperate for the quickest possible way to generate WCF services and/or descriptions, there is no discernable reason to ever choose the Publish BizTalk orchestrations as WCF service option.

The alternative to using orchestrations to define the service contract and communication pattern is to build up the service definition graphically using a schema-only model. Selecting this alternative option allows us to manually name the service, choose a communication pattern, name the service operation, and choose the data contract(s).

To create such an endpoint, once again fire up the BizTalk WCF Service Publishing Wizard and choose the Metadata only endpoint (MEX) as the WCF Service Type. When we are asked which receive location we wish to produce metadata for, select the Seroter.BizTalkSOA.Chapter3.ReceiveNewOrder.WcfTcp location. After choosing to Publish schemas as WCF service on the next wizard page, we are given the opportunity to manually describe the new service.

Here, we apply friendlier names for service attributes, starting with the service description at the top. Note that this attribute cannot have dot operators in the name, so I called it SeroterBizTalkSOAChapter3. This value does NOT show up anywhere in the service itself, but is rather the name of the Visual Studio.NET solution file that the wizard generates for the web service. After renaming the service node OrderService, the existing two-way operation should be deleted. Next, a new operation is added by right-clicking the service, selecting Add web method, and choosing a one-way operation. After changing the operation name to SubmitNewOrder, we need to right-click the Request message and choose to Select schema type. This is where we indicate the input message type that our service expects. Browse to the appropriate BizTalk project assembly, and pick the only available schema type. Our service definition would now look like this:

On the next page of the wizard, set the service namespace to http://Seroter.BizTalkSOA.Chapter3/Service . For the service location, I chose http://localhost/Seroter.BizTalkSOA .Chapter3.OrderManagement.BizTalkMEX. Once the wizard is completed, we have an IIS-deployed metadata endpoint that can be interrogated by WCF clients to reveal the contract and URL for our BizTalk-hosted service. Note that the status of the actual BizTalk endpoint (that is, receive location enabled or disabled) does not impact the availability of the MEX endpoint.

Is this the only way to expose metadata from in-process WCF receive locations? No, but it's the most straightforward way. In a later chapter, I'll show you a more roundabout way to do this that does not require an IIS-hosted metadata service.